home *** CD-ROM | disk | FTP | other *** search
/ SGI Developer Toolbox 6.1 / SGI Developer Toolbox 6.1 - Disc 4.iso / documents / RFC / rfc1372.txt < prev    next >
Text File  |  1994-08-01  |  11KB  |  340 lines
  1.  
  2.  
  3.  
  4.  
  5.  
  6.  
  7. Network Working Group                                         C. Hedrick
  8. Request for Comments: 1372                            Rutgers University
  9. Obsoletes: RFC 1080                                            D. Borman
  10.                                                      Cray Research, Inc.
  11.                                                             October 1992
  12.  
  13.                    Telnet Remote Flow Control Option
  14.  
  15. Status of This Memo
  16.  
  17.    This RFC specifies an IAB standards track protocol for the Internet
  18.    community, and requests discussion and suggestions for improvements.
  19.    Please refer to the current edition of the "IAB Official Protocol
  20.    Standards" for the standardization state and status of this protocol.
  21.    Distribution of this memo is unlimited.
  22.  
  23. Introduction
  24.  
  25.    This document specifies an extended version of the Telnet Remote Flow
  26.    Control Option, RFC 1080, with the addition of the RESTART-ANY and
  27.    RESTART-XON suboptions.
  28.  
  29. 1.  Command Names and Codes
  30.  
  31.    TOGGLE-FLOW-CONTROL   33
  32.        OFF                    0
  33.        ON                     1
  34.        RESTART-ANY            2
  35.        RESTART-XON            3
  36.  
  37. 2.  Command Meanings
  38.  
  39.    IAC WILL TOGGLE-FLOW-CONTROL
  40.  
  41.       Sender is willing to enable and disable flow control upon command.
  42.  
  43.    IAC WONT TOGGLE-FLOW-CONTROL
  44.  
  45.       Sender refuses to enable and disable flow control.  Nothing is
  46.       implied about whether sender does or does not use flow control.
  47.       It is simply unwilling to enable and disable it using this
  48.       protocol.
  49.  
  50.    IAC DO TOGGLE-FLOW-CONTROL
  51.  
  52.       Sender is willing to send commands to enable and disable flow
  53.       control.
  54.  
  55.  
  56.  
  57.  
  58. Hedrick & Borman                                                [Page 1]
  59.  
  60. RFC 1372           Telenet Remote Flow Control Option       October 1992
  61.  
  62.  
  63.    IAC DONT TOGGLE-FLOW-CONTROL
  64.  
  65.       Sender refuses to send command to enable and disable flow control.
  66.  
  67.    IAC SB TOGGLE-FLOW-CONTROL OFF IAC SE
  68.  
  69.       Sender requests receiver to disable flow control.
  70.  
  71.    IAC SB TOGGLE-FLOW-CONTROL ON IAC SE
  72.  
  73.       Sender requests receiver to enable flow control.
  74.  
  75.    IAC SB TOGGLE-FLOW-CONTROL RESTART-ANY IAC SE
  76.  
  77.       Sender requests that when flow control is enabled, the receiver
  78.       allow any character (except another XOFF) to restart output.
  79.  
  80.    IAC SB TOGGLE-FLOW-CONTROL RESTART-XON IAC SE
  81.  
  82.       Sender requests that when flow control is enabled, the receiver
  83.       allows only the XON character to restart output.
  84.  
  85. 3.  Default Specification
  86.  
  87.    The default specification for this option is
  88.  
  89.       WONT TOGGLE-FLOW-CONTROL DONT TOGGLE-FLOW-CONTROL
  90.  
  91.    meaning flow control information will not be exchanged in either
  92.    direction.
  93.  
  94. 4.  Motivation
  95.  
  96.    This memo describes a method of remotely toggling flow control
  97.    between a user telnet process and the attached terminal.  Only flow
  98.    control of data being transmitted from the telnet process to the
  99.    terminal is considered.  Many systems will also allow flow control of
  100.    data from the terminal to the telnet process, however there is seldom
  101.    need to change this behavior repeatedly during the session.
  102.  
  103.    There are two common ways of doing flow control: hardware and
  104.    software.  Hardware flow control uses signals on wires dedicated for
  105.    this purpose.  Software flow control uses one or two specific
  106.    characters sent along the same path as normal input data.  Most
  107.    commonly, XOFF (control-S) and XON (control-Q) are used to stop and
  108.    start output, respectively.  The option described herein is useful
  109.    primarily where software flow control is being used.  (Since hardware
  110.    flow control does not preempt any characters, there is normally no
  111.  
  112.  
  113.  
  114. Hedrick & Borman                                                [Page 2]
  115.  
  116. RFC 1372           Telenet Remote Flow Control Option       October 1992
  117.  
  118.  
  119.    need to disable it.)  It should also be noted that flow control can
  120.    either be generated automatically by the terminal when its buffers
  121.    are close to overflowing, or manually by the user, when he/she cannot
  122.    read the information as fast as it is being displayed, and unread
  123.    information will start scrolling off the screen.
  124.  
  125.    The primary difficulty with software flow control is that it preempts
  126.    one or two characters.  Host software often requires the user to be
  127.    able to input every possible ASCII character.  (Certain editors are
  128.    notorious for having XOFF and XON as commonly-used commands.)  For
  129.    this reason, operating systems often allow programs to disable flow
  130.    control.  While it is disabled, the characters that normally signal
  131.    flow control may be read as normal input.  In a telnet environment,
  132.    flow control is normally done by the user telnet process, not by the
  133.    host computer.  In addition, many operating systems, when flow
  134.    control is enabled, the user may specify whether the XOFF character
  135.    is the only character that is allowed to re-enable the output of
  136.    data, or whether any typed character should re-enable the flow of
  137.    data.  Thus this RFC defines a way to propagate flow control status
  138.    from the host computer to the user telnet process.
  139.  
  140. 5.  Description of the Option
  141.  
  142.    Use of the option requires two phases.  In the first phase, the
  143.    telnet processes agree that one of them will TOGGLE-FLOW-CONTROL.
  144.    WILL and DO are used only in this first phase.  In general there will
  145.    be only one exchange of WILL and DO for a session.  Subnegotiations
  146.    must not be issued until DO and WILL have been exchanged.  It is
  147.    permissible for either side to turn off the option by sending a WONT
  148.    or DONT.  Should this happen, no more subnegotiations may be sent,
  149.    unless the option is re-enabled by another exchange of DO and WILL.
  150.  
  151.    Once the hosts have exchanged a WILL and a DO, the sender of the DO
  152.    TOGGLE-FLOW-CONTROL is free to send subnegotiations to enable and
  153.    disable flow control in the other process, and to send
  154.    subnegotiations for recommendations on when to restart output.
  155.    Normally, the sender of the DO will be a host, and the other end will
  156.    be a user telnet process, which is connected to a terminal.  Thus the
  157.    protocol is normally asymmetric, however it may be used in both
  158.    directions without confusion should need for this arise.
  159.  
  160.    As soon as the DO and WILL have been exchanged, the sender of the
  161.    WILL must enable flow control.  This allows flow control to begin in
  162.    a known state.  The decision of whether to restart output only when
  163.    the XON character is received, or when any character received, starts
  164.    in a system dependent state.  (This is to make it consistent with
  165.    older implementations of the TOGGLE-FLOW-CONTROL option that do not
  166.    understand the RESTART-ANY and RESTART-XON suboptions.)  The sender
  167.  
  168.  
  169.  
  170. Hedrick & Borman                                                [Page 3]
  171.  
  172. RFC 1372           Telenet Remote Flow Control Option       October 1992
  173.  
  174.  
  175.    of the DO should send either a RESTART-ANY or RESTART-XON suboption
  176.    to put the restart characteristics to a know state.  Some clients
  177.    might not be able to support both of the RESTART-ANY and RESTART-XON
  178.    modes due to system limitations, and would then choose to ignore
  179.    these commands.  There is no way for the server to be notified of
  180.    this condition, but a client should make every attempt to honor the
  181.    state requested by the RESTART-ANY and RESTART-XON modes.  Should the
  182.    option be disabled by exchange of DONT and WONT, flow control may
  183.    revert to an implementation-defined default state.  It is not safe to
  184.    assume that flow control will remain in the state requested by the
  185.    most recent subnegotiation.
  186.  
  187.    In most implementations of software flow control, when enabled, the
  188.    XOFF and XON characters are never propagated to the server; they are
  189.    typically eaten by the terminal driver between the telnet client and
  190.    the attached terminal.  In most implementations that support the
  191.    RESTART-ANY functionality, the typed character that re-enables the
  192.    output is not eaten by the terminal driver, unless it is the XON
  193.    character.
  194.  
  195.    Currently, only four command codes are defined for the
  196.    subnegotiations: flow control off (code 0), flow control on (code 1),
  197.    restart output on any character (code 2) and restart output only on
  198.    XON (code 3).  None of these codes requires any additional data,
  199.    however it is possible that additional commands may be added.  Thus
  200.    subnegotiations having command codes other than those defined in this
  201.    document should be silently ignored.
  202.  
  203.    This option does not deal with the issue of allowing the DO side of
  204.    the connection to inform the WILL side which characters should be
  205.    used for XON and XOFF.  That functionality is already supplied by the
  206.    LINEMODE [1] option.
  207.  
  208.  
  209.  
  210.  
  211.  
  212.  
  213.  
  214.  
  215.  
  216.  
  217.  
  218.  
  219.  
  220.  
  221.  
  222.  
  223.  
  224.  
  225.  
  226. Hedrick & Borman                                                [Page 4]
  227.  
  228. RFC 1372           Telenet Remote Flow Control Option       October 1992
  229.  
  230.  
  231. 6.  Example
  232.  
  233.    Here is an example of the use of this option:
  234.  
  235.        Client                           Server
  236.                                         IAC DO TOGGLE-FLOW-CONTROL
  237.        IAC WILL TOGGLE-FLOW-CONTROL
  238.        [ The server is now free to send commands to change flow control.
  239.          Note that the client must now have enabled flow control, but
  240.          that whether it is restart on XON only or on any character is
  241.          client specific.  ]
  242.                                         IAC SB TOGGLE-FLOW-CONTROL
  243.                                         RESTART-ANY IAC SE
  244.  
  245.        [ The client should now switch to allowing output to restart when
  246.          the user types any character, if the client is able to support
  247.          that functionality.  ]
  248.                                         IAC SB TOGGLE-FLOW-CONTROL OFF
  249.                                         IAC SE
  250.                                         IAC SB TOGGLE-FLOW-CONTROL ON
  251.                                         IAC SE
  252.  
  253. References
  254.  
  255.    [1] Internet Engineering Task Force, Telnet Working Group,
  256.        D. Borman, Editor, "Telnet Linemode Option", RFC 1184,
  257.        Cray Research, Inc., October 1990.
  258.  
  259. Acknowledgments
  260.  
  261.    The original specification for this option was written by Charles
  262.    Hedrick, and published as RFC 1080.  The RESTART-ANY and RESTART-XON
  263.    suboptions were defined and added to this version of the document by
  264.    David Borman.
  265.  
  266. Security Considerations
  267.  
  268.    Security issues are not discussed in this memo.
  269.  
  270.  
  271.  
  272.  
  273.  
  274.  
  275.  
  276.  
  277.  
  278.  
  279.  
  280.  
  281.  
  282. Hedrick & Borman                                                [Page 5]
  283.  
  284. RFC 1372           Telenet Remote Flow Control Option       October 1992
  285.  
  286.  
  287. Authors' Addresses
  288.  
  289.    David Borman
  290.    Cray Research, Inc.
  291.    655F Lone Oak Drive
  292.    Eagan, MN 55121
  293.  
  294.    Phone: (612) 452-6650
  295.    Email: dab@CRAY.COM
  296.  
  297.  
  298.    Charles Hedrick
  299.    Director, LCSR Computing Facility
  300.    Rutgers University
  301.    227 CORE Building
  302.    P.O. Box 879
  303.    Piscataway, NJ  08855-0879
  304.  
  305.    Phone: (908) 932-3088
  306.    Email: hedrick@cs.rutgers.edu
  307.  
  308.    Mailing List: telnet-ietf@CRAY.COM
  309.  
  310.  
  311.  
  312.  
  313.  
  314.  
  315.  
  316.  
  317.  
  318.  
  319.  
  320.  
  321.  
  322.  
  323.  
  324.  
  325.  
  326.  
  327.  
  328.  
  329.  
  330.  
  331.  
  332.  
  333.  
  334.  
  335.  
  336.  
  337.  
  338. Hedrick & Borman                                                [Page 6]
  339.  
  340.